After realizing an issue with this implementation, specifically that encoding an object using Codec.canEncode(Object value), would have gotten surprising results into how that object would have been encoded depending on what order DefaultCodecLookup.findEncodeCodec finds them due to having multiple codecs sharing the JTS Geography type.

Given that, I opted for a design that is more semantically correct, i.e. treat Geography the same way that String is treated and make a generic PostgisCodec that supports both geography and geometry in the same way String supports multiple types (VARCHAR, TEXT, NAME etc etc).

This did require touching some other internals i.e. BuiltinDynamicCodecs had to be updated to support retrieving multiple oid's from multiple rows and join them into a single codec (currently only supported one oid per row), but I think the end result is cleaner, better and more idiomatic as just like String, the only difference between Geography and Geometry are internal differences in how Postgres calculates distances, but they both fundamentally represent the same type on a client.